ParallelTalk MVP v1 実装
from ParallelTalk MVP v1
ParallelTalk MVP v1 実装の話はこっちに書く
20230602
気合い入れれば一日で終わると思うので、気分が乗っている今勢いで作り上げるblu3mo.icon
https://www.100ms.live/docs/javascript/v2/how-to-guides/record-and-live-stream/hls/hls
https://github.com/video-dev/hls.js/
https://gyazo.com/68eadcec78119f9e00e04704218eae00
とりあえずwebrtcとhlsの同時表示はできたが、hlsの遅延と不安定さがひどい
遅延を減らす方法を考える
Beam -> ?? -> HLS、という流れ
別の過去映像を得る方法を考える
ローカルで記録?
これありかもしれない
WebRTCで中央サーバーにあるバッファを取れない?
YouTube Stream API
これはまあプロトタイプだけだな
未来の自分に作業配信を作りつつ、YouTube Stream APIの調子を探る
https://gyazo.com/3933181da2a18d51289dad7a1244caef
普通にめっちゃ金が飛ぶ〜
やっぱ100msにここは頼れなさそうだな
https://chat.openai.com/share/7ab91389-2740-4d11-a5a3-dc1b5645e0a0
ローカルに持つ方法がいけそうblu3mo.icon*2
MediaRecording API
ちらつき発生
https://www.tilcode.com/react-fixing-flickering-video-redraw/
Use a double buffering technique: Create two video elements and switch between them while updating the source of the non-visible one. This way, the update won't be visible to the user, and you can avoid the flickering effect.
これ、PiPが壊れるのでまずいな
Update the video src less frequently: Instead of updating the src every 5000ms, try increasing the interval to a larger value. This will reduce the number of times the video flickers, although it may not completely eliminate the issue.
Concatenate the chunks before updating the src: Instead of updating the src with the latest chunk, try concatenating all the chunks and updating the src once the recording is stopped. This way, the flickering will only happen once, at the end of the recording.
Use a custom video player: Utilize a custom video player like Video.js or Plyr with better buffer handling capabilities. These players may provide a smoother playback experience and handle the src updates more efficiently, reducing the flickering effect.
自由度は高い方が後々良いだろうし、Video.js試すかblu3mo.icon
Implement a custom buffer management system: Instead of relying on the browser's default buffer handling, implement a custom buffer management system that can handle the src updates more efficiently. This may involve using a combination of the MediaSource API and SourceBuffer API to manage the video playback and reduce flickering.
これだなblu3mo.icon
https://stackoverflow.com/questions/50333767/html5-video-streaming-video-with-blob-urls/50354182
https://qiita.com/soebosi/items/74464d2f34d7416336eb
20230304
作りたいMVPのイメージは固まっているので、週末を使ってが〜っと実装したい
せっかく課題が何もない週末なので、うまく使いたい
ハッカソン気分
小さくても成り立っている物を作る
1. ただwebで通話できるもの ✅
2. 通話できる & 遡って音声を聞けるもの
3. ルームを分かれることができるもの
4. 各ルームとそのログを表示するGUI
5. 文字起こし + 早送り
ここまで作れれば目標達成といえそう
Sat
最低1, できれば2を目指したい
1 done、まじで100msのデモ動かすだけだった✅
Sun
2がちゃんとできていれば、3, 4, 5はやるだけ感がある
3はちょっと100msの仕様が不安だな
通話できる & 遡って音声を聞けるもの
HLS配信
https://www.100ms.live/blog/hls-streaming
至れり尽くせりだな
100ms supports live streaming output via HLS. However, we use WebRTC as input for the stream, unlike services that offer the infrastructure for live streaming alone, which generally use RTMP.
なるほど〜blu3mo.icon
元々Kinetoもこうしようと思っていたけど、途中でRMTP->HLSに変えた
映像の記録は72hまで100msがやってくれる
それ以上はAWSと連携しろって
SFU Recording
p2pではなく中央経由でWebRTCをやる時に、それを記録するやつか
どちらにせよHLSで配信しないとなので、とりあえずこれは放置で良いかな
というか100ms-webは機能がおおすぎて辛い
もっとシンプルなやつをいじっていきたい
https://github.com/100mslive/clubhouse-clone-react
これがシンプルなものの中では良さそう?
https://www.100ms.live/blog/clubhouse-clone-react
これを動かすか
20230131
https://www.100ms.live/examples/live-streaming-starter-kit
これがベースになりそうblu3mo.icon
「ブランチを切る」
一人でHEADにいる場合も、HEADに二人がいる場合も、内部的には同じ状態
空白部分は再生時にカットしてあげれば良さそう
技術書典で空白部分をカットするアルゴリズムを紹介する本があったu7693.icon
Voicy Tech Story vol.4
https://techbookfest.org/product/dAJMsLnuGbnRYwQHX1sW9z
実装としては、全員WebRTCの同じルームにいて貰えば実装が楽そうだし帯域幅も食わない
ブランチを切ったときは、クライアント側(?)で音量を調節して、お互いが聞こえないようにする
100ms、特定の人の声を聞こえないようにする、出来そうblu3mo.icon
MVPの先だけど、ParallelTalkで、他のブランチの声もうっすら聞こえるみたいな演出もあってよさそう